This guide identifies features and functionality added or modified between software releases 8.x and 9.0. Topics covered in this chapter are:
Additional information on these items is located in the documents provided with the 9.0 release, see the table below.
This feature provides dynamic MPLS label support for ingress and egress traffic where system works as MPLS-Customer Edge system and maintains VRF routes in various VRFs and exchanges route information with peer over MP-eBGP session with an Autonomous System Border Router (ASBR).
In deployment scenario the MPLS-CE system maintains VRF routes in various VRFs and exchanges route information with peer over MP-eBGP session with peer. The peer in this scenario is not a PE router but an ASBR. The ASBR does not need to maintain any VRF configuration. The PE routers use IBGP to redistribute labeled VPN-IPv4 routes either to an Autonomous System Border Router (ASBR), or to a route reflector of which an ASBR is a client. The ASBR then uses eBGP to redistribute those labeled VPN-IPv4 routes to MPLS-CE in another AS. Because of eBGP connection, ASBR changes the next-hop and labels in the routes learnt from iBGP peers before advertising to MPLS-CE. MPLS-CE is directly connected eBGP peering and uses only MP-eBGP to advertise and learn routes. MPLS-CE pushes/pops single label to/from ASBR, which is learnt over MP-eBGP connection. This scenario uses dynamic MPLS label and avoids configuration of VRFs on PE, which are already configured on MPLS-CE.
For more information on functioning and configuration of this interface, refer Multiple Protocol Lable Switching chapter in System Enhanced Feature Configuration Guide.
Starent chassis provides the redundancy scheme for using top and bottom line card slots for one-to-one redundancy for line cards with top and bottom line card slot for one-to-one redundancy.
The XGLC is a full-height card that requires both top and bottom line card slots for a single 10-gigabit port. This means that the scheme for using top and bottom line card slots for one-to-one redundancy is not workable for XGLCs. To achieve one-to-one line card redundancy, user must install two XGLCs in adjacent slots. Otherwise, user can configure port and card redundancy for the XGLCs in the same way as other line cards. There are no restrictions that prevent the side-to-side 1:1 XGLC redundant arrangement from functioning with other Ethernet line card types.
Each PSC or PSC2 is mated to a single XGLC. Monitoring functions occur in a distributed fashion. Select the line cards that act as a redundant pair via the CLI. Configure the redundant pairs prior to configuring the interface bindings so that proper parallel physical and logical port configurations are established. The card redundancy and monitoring begins as soon as the PSC or PSC2 in front is active.
Note: Side-by-side 1:1 redundancy only operates on top line card slot numbers: cards 17 through 23 and 26 through 32. Make sure that both PSCs or PSC2s in front of the line cards are of the same type, configured as a redundant pair, and active.
For more information on side by side 1:1 redundancy for 10 Gig line card (XGLC), refer ST40 Hardware Installation Guide.
The PPC has features a quad-core x86 2.5Ghz CPU and 16GB of RAM. The processor runs a single copy of the operating system. To check the CPU in the CLI, use the show cpu table command. The operating system running on the PPC treats the dual-core processor as a 2-way multi-processor. You can see this in the output of the show cpu info verbose command.
A second-generation data transport fixed programmable gate array (DT2 FPGA, abbreviated as DT2) connects the PPC’s NPU bus to the switch fabric interface. The FPGA also provides a bypass path between the line card or Redundancy Crossbar Card (RCC) and the switch fabric for ATM traffic. Traffic from the line cards or the RCC is received over the FPGA’s serial links and is sent to the NPU on its switch fabric interface. The traffic destined for the line cards or RCC is diverted from the NPU interface and sent over the serial links.
DT2 FPGA also connects to the control processors subsystem via a PCI-E bus. The PCI-E interface allows the control processors to perform register accesses to the FPGA and some components attached to it, and also allows DMA operations between the NPU and the control processors’ memory. A statistics engine is provided in the FPGA. Two reduced latency DRAM (RLDRAM) chips attached to the FPGA provide 64MB of storage for counters.
The PPC has a 2.5 G/bps-based security processor that provides the highest performance for cryptographic acceleration of next-generation IP Security (IPsec), Secure Sockets Layer (SSL) and wireless LAN/WAN security applications with the latest security algorithms.
This release supports peer selection using IMSI prefix or suffix, or IMSI prefix or suffix range. Subscribers are now assigned to a primary OCS instance based on the IMSI prefix or suffix of a length of 1 to 15 digits. If the prefix or suffix keyword is not specified, the suffix will be considered. Up to 64 peer selects can be configured. At any time, either prefix or suffix mode can be used in one DCCA config. If the prefix or suffix mode is used, the lengths of all prefix/suffix must be equal.
In earlier StarOS 9.0 releases, whenever CDR transfer mode push was configured with a remote URL, on the external server the chassis would by default create an extra directory in the base directory path before creating the edr/udr directories.
This enabled to keep EDR and UDR files from multiple chassis pushing to the same external server with same base directory separate.
In the current release, the default behavior has changed, the extra directory with the chassis host name will not be created on the external server. This behavior is the same as in the StarOS 8.x releases. The directory structure will be:
As defined by the 3GPP standards, the R7 Gx interface is located between the GGSN and the Policy Decision Function (PDF) / Policy and Charging Rule Function (PCRF). It is a Diameter-based interface and provides the functions provided earlier by the Gx (R6) and Go interfaces. Gx interface as part of a Policy / PCC framework allows the operator to have dynamic policy and charging control, key features when “flat rate” broadband services are offered. However, it is paramount that the operator maintains control over the available resources, and provides a fair usage policy to its subscribers, via bandwidth control, quota management and other mechanisms.
|
l
|
Ability to define static policies to deny and allow based on 5-tuple information; ability to enable and disable from the PCRF
|
In previous releases, in case of PCRF-based binding, when the bearer-level QoS information was received from PCRF without bearer ID, the UPC request with the change in QoS was sent to the default bearer.
In this release, this behavior has changed. In case of PCRF-based binding, the bearer ID is expected as part of the bearer-level QoS information from the PCRF. Otherwise the QoS information is ignored.
In previous releases, the bearer ID in the QoS-Information AVP from the PCRF was not being validated at the PCEF.
In StarOS 8.1 and earlier releases, when the failure handling action configured under the IMSA service is terminate, and if the primary server is down but the secondary server is up during call establishment, the call is terminated.
In StarOS 8.0, if in the APN configuration both the virtual APN name and Gn APN name are configured, the virtual APN name is sent in the Gx messages.
In this release, if both the virtual APN name and Gn APN name are configured, the Gn APN name is sent in the Gx messages. In case only the Gn APN name is configured, the Gn APN name is sent.
In previous releases, there was no limit check for the number of Charging-Rule-Definition AVPs (dynamic rules) that are processed in a single Gx CCA command. In StarOS 9.0, the number of dynamic rules is limited to 100 per Gx message.
In this release, whenever the PCRF subscribes to one or more event triggers by using the RAR command, the PCEF sends the corresponding currently applicable values (e.g. 3GPP-SGSN-Address AVP or 3GPP-SGSN-IPv6-Address AVP, RAT-Type, 3GPP-User-Location-Info, etc.) to the PCRF in the RAA if available, and in this case, the Event-Trigger AVPs will not be included.
In StarOS 8.1, if PCRF does not authorize the requested QoS values, the PCEF does not reject the Gx response messages.
In StarOS 9.0, if the PCRF does not authorize the requested QoS values, or if QoS values previously authorized by the PCRF are not available, the PCEF rejects the Gx messages from PCRF and the corresponding access side procedure. The Max Uplink/Downlink, Guaranteed Uplink/Downlink parameters are considered to check whether the QoS values are authorized or not. Validation is done across all Gx messages.
This release introduces support for Category-based Static-and-Dynamic Content Filtering, wherein if static rating categorizes a URL as either “dynamic” or “unknown”, the “requested content” is sent for dynamic rating. Wherein the “requested content” is analyzed and categorized. Action is taken based on the category determined by dynamic rating, and the action configured for that category in the subscriber’s content filtering policy. Possible actions include permitting, blocking, redirecting, and inserting/altering content.
Dynamic Content Filtering enables on-the-fly content analysis of Web traffic using different content analysis techniques. When a Web page is received, it is analyzed and then categorized according to the content found in the page. Whether a Web site has existed for five months or for five minutes does not matter since determination of the category to which the Web page belongs is made just at the time of request. A combination of static filtering and dynamic inspection provides real accuracy and scalability as the Web weaves an increasingly sophisticated network of sites.
IMPORTANT: Category-based Content Filtering can only work in static-only or in static-and-dynamic modes. Dynamic-only Content Filtering mode is not supported.For more information, refer to the Content Filtering Services Administration Guide.
EDR Generation in Flow-end and Transaction Complete Scenarios with sn-volume Fields
In this release sn-volume-amt counters will be re-initialized only when the fields are populated in EDRs. For example, consider the following two EDR formats:
Previously, if edr2 was generated, even though sn-volume-amt fields are not populated, sn-volume-amt counters (uplink bytes, uplink packets, downlink bytes, downlink packets) were re-initialized. So the total volume reflected by EDRs in sn-volume-amt counters was less than the actual count.
In this release, sn-volume-amt counters will be re-initialized only if these fields are populated in the EDRs. Now, if edr2 is generated, these counters will not be re-initialized. These will be re-initialized only when edr1 is generated.
Also, note that only those counters will be re-initialized which are populated in EDR. For example, in the following EDR format:
If edr3 is generated, only uplink bytes and downlink bytes counters will be re-initialized and uplink packets and downlink packets will contain the previous values till these fields are populated (say when edr1 is generated).
StarOS 9.0 introduces support for IPv6 and ICMPv6 packets and their parsing in the Enhanced Charging Service.
ECS can now parse both IPv4 and IPv6 packets and pass them to upper layers for analysis. ECS will match the rule based on IPv6 fields and generate various statistics for IPv6 packets. Dynamic routing used by various analyzers like FTP, RTSP, RTP, and SIP also supports IPv6 addresses.
The enhancement to ECS in Release 9.0 provides appropriate CLIs to configure IPv6 fields in rules and EDRs. Various CLIs are provided to configure rules related to IPv6 fields for charging and routing. Several fields in EDRs give IP address. ECS will also support IPv6 addresses in these EDR fields. Show command CLIs which show IP addresses support IPv6 addresses as well. The various logs in ECS which log IP addresses along with other information, supports IPv6 addresses as well. ECS supports various header fields of IPv6 in EDRs. In config-acs-edr mode, ECS supports generating EDRs for IPv6 fields.
StarOS 9.0 also supports ICMPv6 packets and their parsing in ECSv2. The header structure of ICMP and ICMPv6 is similar but the values of header fields like type and code have different meaning in the two.
This release supports the URL Filtering feature, which simplifies using rule definitions for URL detection. Prefixed URLs are URLs of the proxies. A packet can have a URL of the proxy and the actual URL contiguously. First a packet is searched for the presence of proxy URL. If the proxy URL is found, it is truncated from the parsed information and only the actual URL (that immediately follows it) is used for rule matching and EDR generation.
For more information, refer to the Enhanced Charging Service Administration Guide.
This section contains information on new 9.0 features that pertain to the HRPD Serving Gateway (HSGW) and the PDN Gateway (P-GW) supporting eHRPD network services.
The HSGW terminates the eHRPD access network interface from the Evolved Access Network/Evolved Packet Core Function (eAN/ePCF) and routes UE-originated or terminated packet data traffic. It provides interworking with the eAN/ePCF and the PDN Gateway (P-GW) within the Evolved Packet Core (EPC) or LTE/SAE core network and performs the following functions:
|
l
|
Transport level packet marking in the uplink and the downlink, e.g., setting the DiffServ Code Point, based on the QCI of the associated EPS bearer
|
|
l
|
Uplink bearer binding verification with packet dropping of UL traffic that does not comply with established uplink policy
|
The P-GW terminates the SGi interface towards the Packet Data Network (PDN). If a UE is accessing multiple PDNs, there may be more than one P-GW for that UE. The P-GW provides connectivity to the UE to external packet data networks by being the point of exit and entry of traffic for the UE. A UE may have simultaneous connectivity with more than one P-GW for accessing multiple PDNs. The P-GW performs policy enforcement, packet filtering for each user, charging support, lawful interception and packet screening.
Another key role of the P-GW is to act as the anchor for mobility between 3GPP and non-3GPP technologies such as WiMAX and 3GPP2 (CDMA 1X and EvDO).
|
l
|
Mobility anchor for mobility between 3GPP access systems and non-3GPP access systems. This is sometimes referred to as the SAE Anchor function.
|
|
l
|
Local Mobility Anchor (LMA) according to draft-ietf-netlmm-proxymip6, if PMIP-based S5 or S8 is used.
|
This section contains information on features that pertain to the Local-External Storage Server (L-ESS) and Remote (Long Term)-External Storage Server (R-ESS).
In this release, the L-ESS is designed to support simultaneous fetching of any types of files from one or more chassis. That is, it can fetch CDR, EDR, NBR, UDR file, etc.
The current design of L-ESS allows dynamic configuration of source and destination. This further allows multi-threading and multi-processing of the associated hardware components, thereby improving the performance of L-ESS.
In previous releases, the Stateful Firewall license was required to enable and configure NAT. In this release, Stateful Firewall and NAT licenses are separated.
The “[600-00-7808] Stateful Firewall With DPI” license has been obsoleted.
Stateful Firewall must be enabled and configured using the “[600-00-7571] Per Subscriber Stateful Firewall 1k sessions” license. This license enables CLI privileges only for Enhanced Charging Service (ECSv2) and Per Subscriber Stateful Firewall. NAT features cannot be enabled/configured with this license. Some CLI commands that are common to both Stateful Firewall and NAT are available with either Stateful Firewall or NAT license.
GRE protocol functionality adds one additional protocol on ST-series Multimedia Core Platforms (ST40 or higher) to support mobile users to connect to their enterprise networks through Generic Routing Encapsulation (GRE).
GRE tunnels can be used by the enterprise customers of a carrier 1) To transport AAA packets corresponding to an APN over a GRE tunnel to the corporate AAA servers and, 2) To transport the enterprise subscriber packets over the GRE tunnel to the corporation gateway.
The corporate servers may have private IP addresses and hence the addresses belonging to different enterprises may be overlapping. Each enterprise needs to be in a unique virtual routing domain, known as VRF. To differentiate the tunnels between same set of local and remote ends, GRE Key will be used as a differentiator.
GRE Tunneling is a common technique to enable multi-protocol local networks over a single-protocol backbone, to connect non-contiguous networks and allow virtual private networks across WANs. This mechanism encapsulates data packets from one protocol inside a different protocol and transports the data packets unchanged across a foreign network. It is important to note that GRE tunneling does not provide security to the encapsulated protocol, as there is no encryption involved (like IPSEC offers, for example).
|
l
|
Carrier protocol-protocol that does the encapsulating. For example: GRE, IP-in-IP, L2TP, MPLS and IPSEC.
|
|
l
|
The most simplified form of the deployment scenario is shown in the following figure, in which GGSN has two APNs talking to two corporate networks over GRE tunnels.
Apart from other command configuration addition/modifications in various configuration modes, following new configuration modes were added to Command Line Interface for this feature support:
For more information on functioning and configuration of this interface, refer GRE Protocol Interface chapter in System Enhanced Feature Configuration Guide.
This solution provides the ability to configure mobile carriers to maximize their network solutions and balancing the requirements to accurately bill their customer.
Consider scenario where a mobile is streaming or downloading very large files from external sources and the mobile goes out of radio coverage. If this download is happening on Background/Interactive traffic class then the GGSN is unaware of such loss of connectivity as SGSN does not perform the Update PDP Context procedure to set QoS to 0kbps (this is done when traffic class is either Streaming or Conversational only). The GGSN continues to forward the downlink packets to SGSN. In the loss of radio coverage, the SGSN will do paging request and find out that the mobile is not responding; SGSN will then drops the packets. In such cases, the G-CDR will have increased counts but S-CDR will not. This means that when operators charge the subscribers based on G-CDR the subscribers may be overcharged. This feature is implemented to avoid the overcharging in such cases.
This implementation is based on Starent-specific private extension to GTP messages and/or any co-relation of G-CDRs and S-CDRs. It also does not modify any RANAP messages.
For more information of this feature, refer Subscriber Overcharging Protection chapter in System Enhanced Feature Configuration Guide.
Release 9.0 enables support for multiple data streams from one server or a single cluster setup to utilize multiple instances of GSS with a single installation and multiple databases.
In a cluster setup, there is only one installation per node. During installation, GSS is installed at a fixed location (/opt/gss_global directory). The initial GSS installation does not create any GSS instance. Once GSS is installed on both the nodes, the /opt/gss_global/make_gss_instance script utility creates instances as an when needed and validates the conflicting ports/username across the instances.
For all instances on the node, only one set of binaries and scripts are used. Each instance will have its own configuration file, log directory, tools directory and separate PostgreSQL database. The alarms and events generated by each instance are sent to its corresponding chassis. Individual GSS instance can also be stopped, started or switched over. Upgrade is smooth and will involve minimum down time as possible.
Each GSS instance can be uninstalled separately and will not have any impact on the other instances. Global installation can be only uninstalled if there are no instances configured or running on the system.
For more information on the installation, uninstallation and upgrade procedures for multiple GSS instances, refer to Multiple Instances of GSS section in GSS Installation Management chapter of GSS Installation and Administration Guide.
This feature enables support for disk monitoring of shared postgres and gss installation disk partition along with GSS data files disk partition. This feature is supported only for single instance GSS, and for GSS in cluster mode.
This feature can be enabled after installation by configuring specific parameters in the gss configuration file. For information on configuring the parameters, refer to the Modifying a GSS Configuration section in the GTPP Storage Server Administration chapter of GSS Installation and Administration Guide.
IMPORTANT: This feature does not support backward compatibility and hence GSN build should always match with GSS build.The Bulkstat report provides details of the processed bulk statistics from any application (PDSN, GGSN, SGSN, and so on) on the managed nodes in a timely manner. Users need to be assigned to the Region levels so that when a user logs in to the inPilot Server, the data can be viewed for all nodes under the parent node. Only the Admin users are assigned to the top of the tree (root node or NOC node) and have access to the whole network data. The Bulkstat Report can be viewed for the desired bulkstats by selecting the BULKSTAT tab.
The KPI report provides details of the KPIs for each selected schema. The KPI Report can be viewed for the desired KPIs by selecting the KPI tab.
To export a report to PDF format, in the HOME and DPI REPORTS tabs of the inPilot GUI, click the Export to PDF button. The PDF file is displayed in a new window and can be saved for future reference. If there is no data available for a report, the Export to PDF button is disabled.
The inPilot application and its components can be installed and uninstalled using one of the following two methods.
After inPilot upgrade to newer versions, the log files are generated at /starbi/logs/ directory as against the /starbi/server/logs directory in previous releases.
RAT Type reports are generated only if a RAT-type variable is available in EDRs. The RAT related parameters are applicable only for a GGSN call.
If a RAT-type variable is not available, then all the traffic is displayed as Unclassified RAT Type in RAT Type reports. This is the case for a PDSN call.
inPilot now recommends the ZFS file system with two ZFS pools for Sun Microsystems Netra™ T5220 and Sun Microsystems Netra™ X4450 servers. The inPilot installation procedure also includes a checkpoint for ZFS when the user performs installation on a non-ZFS partition path.
The TopN VCD Subscribers report displays the top N subscribers based on their voice usage (voice duration) for Yahoo, MSN and Skype voice protocols. The summary report displays the voice summary (voice duration) for VoIP category.
For more information on the above mentioned features, refer to inPilot Installation and Administration Guide and inPilot Online Help.
This section contains information on new 9.0 features that pertain to the PDN Gateway (P-GW), the Mobility Management Entity (MME) and the Serving Gateway (S-GW) supporting LTE network services.
The P-GW terminates the SGi interface towards the Packet Data Network (PDN). If a UE is accessing multiple PDNs, there may be more than one P-GW for that UE. The P-GW provides connectivity to the UE to external packet data networks by being the point of exit and entry of traffic for the UE. A UE may have simultaneous connectivity with more than one P-GW for accessing multiple PDNs. The P-GW performs policy enforcement, packet filtering for each user, charging support, lawful interception and packet screening.
|
l
|
DL rate enforcement based on AMBR (Aggregate Max Bit Rate) and based on the accumulated MBRs of the aggregate of SDFs with the same GBR QCI
|
The MME resides in the control plane and manages states (attach, detach, idle, RAN mobility), authentication, paging, mobility with 3GPP 2G/3G nodes (SGSN), roaming, and other bearer management functions. The MME is the key control-node for the LTE access-network. The MME provides the following basic functions:
|
l
|
|
l
|
|
l
|
Transparent transfer of HRPD signalling messages and transfer of status information between E-UTRAN and HRPD access, as specified in the pre-registration and handover flows
|
The Serving Gateway routes and forwards data packets from the UE and acts as the mobility anchor during inter-eNodeB handovers. Signals controlling the data traffic are received on the S-GW from the MME which determines the S-GW that will best serve the UE for the session. Every UE accessing the EPC is associated with a single S-GW.
For each UE associated with the EPS, there is a single S-GW at any given time providing the following basic functions:
|
l
|
mobility anchoring for inter-3GPP mobility (terminating S4 and relaying the traffic between 2G/3G system and P-GW)
|
|
l
|
ECM-IDLE mode downlink packet buffering and initiation of network triggered service request procedure
|
|
l
|
transport level packet marking in the uplink and the downlink (e.g. setting the DiffServ Code Point)
|
This section contains information for new features in the Network Address Translation (NAT) product in Release 9.0.
In previous releases, the Stateful Firewall license was required to enable and configure NAT. In this release, Stateful Firewall and NAT licenses are separated.
The “[600-00-7804] NAT/PAT Without DPI” license has been obsoleted.
NAT must now be enabled and configured using the “[600-00-7805] NAT/PAT With DPI” license. This license enables CLI privileges only for Enhanced Charging Service (ECSv2) and NAT/PAT with DPI. Stateful Firewall features cannot be enabled/configured with this license. Some CLI commands that are common to both NAT and Stateful Firewall will be available with either NAT or Stateful Firewall license.
The PDG/TTG is a new product in Release 9.0. The PDG/TTG enables mobile operators to provide Fixed Mobile Convergence (FMC) services to subscribers with dual-mode handsets and dual-mode access cards via WiFi access points. The PDG/TTG makes it possible for operators to provide secure access to the operator’s 3GPP network from a non-secure network, reduce the load on the macro wireless network, enhance in-building wireless coverage, and make use of existing backhaul infrastructure to reduce the cost of carrying wireless calls.
This PDG/TTG software release provides TTG functionality. The TTG is a network element that enables 3GPP PDG functionality for existing GGSN deployments. The TTG and the subset of existing GGSN functions work together to provide PDG functionality to the subscriber UEs in the WLAN.
The PDG/TTG is a licensed product. For information about PDG/TTG licenses, contact your Starent representative.
IMPORTANT: This PDG/TTG software release provides TTG functionality only. PDG functionality is not supported in this release.|
l
|
The PDIF can be configured with multiple IPsec traffic classes, each containing up to 128 traffic selectors, which are used during traffic selector negotiation with UEs. Multiple traffic selectors allow the PDIF to direct outbound traffic to selected IP addresses based on the following protocols: IP, TCP, UDP, and ICMP. The PDIF can also direct TCP and UDP traffic to selected IP addresses and port ranges.
For mobile IP calls, the Selective Diameter Profile Update Request Control feature allows WiFi data-only sessions to co-exist with VoIP sessions on the PDIF platform.
When the PDIF is accessed by voice-enabled devices, it needs to interact with the HSS in order for a subscriber session to access the IP core network. When the PDIF is accessed by data-only devices, there is no need to interact with the HSS.
This feature is used to identify which subscriber sessions need to have the PDIF and the HSS exchange Diameter Profile Update Request (PUR) and Profile Update Answer (PUA) messages, and allows the PDIF to handle the call setup for a data-only client without having to interact with the HSS.
Selective PUR profiles on the AAA server are mapped to subscribers during AAA authentication via the Radius vendor-specific attribute (VSA) FMC-Type. FMC-Type has these possible values: voice or data. When the AAA server sets the FMC-Type value to voice, the PDIF and the HSS exchange PUR and PUA messages. When the AAA server sets the FMC-Type value to data, the PDIF and the HSS do not exchange PUR and PUA messages.
For more information about PDIF features and functions, see the Packet Data Interworking Function Administration Guide.
P2P traffic detection is tricky because most of the P2P protocol details are proprietary, and the protocol characteristics change frequently. As these P2P standards are proprietary, there is a tight coupling between the peers too (all the peers need to understand the protocols). Since P2P detection depends heavily on the known traffic characteristics the detection can suffer if the P2P protocol changes, if some existing traffic characteristics were not known (new use case scenarios), if one P2P traffic characteristic matches with another P2P traffic (false positives), and if there are flaws (bugs) in the detection logic. Whenever such degradation in P2P detection logic is identified, the P2P detection logic must be enhanced to improve the detection accuracy.
In the earlier releases, the P2P detection logic was part of the ST-chassis software load (ST16/ST40 software), to continue to detect new traffic patterns based on the changing traffic characteristics, operators needed to upgrade the complete software with the updated detection logic.
This release supports dynamic upgrades of the P2P detection logic (signatures) alone on an active ST16/ST40 without warranting a full software upgrade, and hence without a software restart or reboot. This is implemented through signature files.
IMPORTANT: This release supports dynamic signature upgrades for the following P2P protocols:Bittorrent, DirectConnect, eDonkey, Gnutella, Skype, Yahoo
For more information, see the Peer-to-Peer Detection Administration Guide.
|
l
|
|
l
|
|
l
|
With release 9.0, the system supports enhanced detection accuracy, for charging purposes, for the following P2P protocols:
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
This section provides information for new features in Release 9.0 for the Session Control Manager (SCM). Additional information on these features can be found in the Session Control Manager Overview section of the Product Overview, in the Session Control Manager Administration Guide, and in the CLI Reference Guide.
In addition, IPv4-IPv6 interworking helps an IPv4 IMS network transition to an all-IPv6 IMS network.
P-CSCF will provide IPv4-IPv6 interworking functionality between IPv6-only UEs and IPv4-only core network elements (I/S-CSCF) by acting as a dual stack. To achieve the dual-stack behavior, P-CSCF will be configured in two services with the first service (V6-SVC) listening on an IPv6 address and the second service (V4-SVC) listening on an IPv4 address. SIP messages coming from IPv6 UEs will come to V6-SVC and will be forwarded to the IPv4 core network through V4-SVC. Similarly, messages from the IPv4 core network come to V4-SVC and will be forwarded to IPv6 UEs via V6-SVC. P-CSCF also provides interworking functionality between IPV4-only UEs and IPv6-only core network elements.
To identify the need for v4-v6 interworking for a new incoming IPv6 REGISTER arriving at V6-SVC, a route lookup is performed based on the request-uri, first in V4-SVC context and then in V6-SVC context if the first lookup does not return any matching route entry. If a matching IPv4 next-hop route entry is found, then this indicates that interworking needs to be done. If no route entry is found, then a DNS query on request-uri domain is done for both A and AAAA type records. If DNS response yields only an IPv4 address, then this is also the case for performing v4-v6 interworking.
Headers (such as Via, Path, etc.) are automatically set to IPv4 bind address of P-CSCF V4-SVC. Remaining headers will be not be altered and sent as is toward the S-CSCF. The IPv4 address in a Path header received from S-CSCF in 200Ok of REGISTER will be replaced with V6-SVC’s IPv6 address before forwarding to UE.
This section provides information for new features in Release 9.0 for the Serving GPRS Support Node (SGSN). Additional information on these features can be found in the SGSN Overview section of the Product Overview, in the SGSN Administration Guide, and in the CLI Reference Guide.
The lower boundary for the 1-in-N IMEI check timer has been changed to 1 second. Now the configurable timeout range is 1 to 30 seconds, with a default of 15 seconds.
For more information, refer to the MAP Service Configuration Mode chapter of the Command Line Interface Reference.
Operators can configure a “default APN” for subscribers not provisioned in the HLR. This feature is available in releases 8.1 and higher.
The Default APN feature will be used in error situations when the SGSN cannot select a valid APN via the normal APN selection process. Within an operator policy, a default APN can be configured for the SGSN to: override a requested APN when the HLR does not have the requested APN in the subscription profile. provide a viable APN if APN selection fails because there was no “requested APN” and wildcard subscription was not an option.
In either of these instances, the SGSN can provide the default APN as an alternate behavior to ensure that PDP context activation is successful.
Refer to the SGSN Operator Policy Configuration Mode in the Command Line Interface Reference for the command to configure this feature.
In accordance with RANAP standards, the Signaling Indication IE is only included in RANAP messages RANAP (RAB Assignment Request and/or the Relocation Request messages) when the traffic class is “interactive”.
The Command Line Interface (CLI) has been modified to enable the operator to control whether the IE is included if both of the following conditions are met:
New CLI commands have been added to the RNC configuration mode to govern the inclusion of the Signaling Indication IE in RANAP messages. Refer to the Command Line Interface Reference for information on enabling/disabling this feature.
A new command has been created to enable the operator to further control message length by configuring the number of IuConIDs sent in each SGSN Init Reset Resource message.
This change will have no impact on current or future configurations as the previously coded system value was 250.
Refer to the RNC Configuration Mode chapter of the Command Line Interface Reference for additional information.
The following limits for release 9.0 have been modified in the Engineer Rules appendix of the SGSN Administration Guide.
|
l
|
Max # of packets buffered -- rules have been clarified:
- Minimum of 2KB/subscriber. - Maximum of 10KB/subscriber -- if buffers are available in the shared pool*. (*SGSN provides a buffer pool of 10M per session manager - buffer to be shared by all subscribers “belonging” to that session manager.) |
The SGSN now supports Phase 1 LI Buffering. For details, please contact your customer sales or support representative.
The SGSN can now be configured to cap the QoS bit rate parameter when the subscribed QoS provided by the HLR is lower than the locally configured value.
Depending upon the keywords included in the command, the SGSN can: take the QoS parameter configuration from the HLR configuration. take the QoS parameter configuration from the local settings for use in the APN policy. during session establishment, apply the lower of either the HLR subscription or the locally configured values.
Refer to the SGSN APN Policy Configuration Mode chapter of the Command Line Interface Reference for the qos command.
With this feature, the 3G SGSN now supports more than one PLMN ID per SGSN. Multiple PLMN support facilitates MS handover from one PLMN to another PLMN.
Multiple PLMN support also means an operator can 'hire out' their infrastructure to other operators who may wish to use their own PLMN IDs. As well, multiple PLMN support enables an operator to assign more than one PLMN ID to a cell-site or an operator can assign each cell-site a single PLMN ID in a multi-cell network (typically, there are no more than 3 or 4 PLMN IDs in a single network).
This feature is enabled by configuring, within a single context, multiple instances of either an IuPS service for a single 3G SGSN service. Each IuPS service is configured with a unique PLMN ID. Each of the SGSN services must use the same MAP, SGTPU and GS services so these only need to be defined one-time per context.
Overcharging Protection enables the SGSN to avoid overcharging the subscriber if/when a loss of radio coverage (LORC) occurs.
When a mobile is streaming or downloading files from external sources (via background or interactive traffic class) and the mobile goes out of radio coverage, the GGSN is unaware of such loss of connectivity and continues to forward the downlink packets to the SGSN.
To accommodate such situations, the SGSN can be configured to set a proprietary private IE extension to set the QoS to 0kbps upon a loss of radio coverage occurs. This setting notifies the GGSN of the LORC to prevent overcharging.
Refer to the SGSN APN Policy Configuration Mode chapter of the Command Line Interface Reference for the command to configure the GTPC private extension and refer to the IuPS Service Configuration Mode chapter of the Command Line Interface Reference to configure the LORC Cause IE.
The SGSN now supports the Packet Services Card 2 (PSC2), the next-generation packet forwarding card for the ST40. The PSC2 provides increased aggregate throughput and performance, and a higher number of subscriber sessions. For more information about this card, refer to the “SGSN Overview” in the SGSN Administration Guide and the ST40 Hardware Installation and Administration Guide.
The CLI has been modified to allow the operator to configure suppression of the Paging Cause IE in a Paging Request. As well, the operator has been given the ability to configure the cause value for various paging sources.
For details, refer to the ranap command in the RNC Configuration Mode chapter of the Command Line Interface Reference.
Usage of the GPRS encryption algorithm (GEA) significantly affects the SGSN processing capacity depending upon the GEAx level used - GEA1, GEA2, or GEA3.
Operators could use a mechanism that would enable them to identify the percentages of their customer base that are using the various GEA encryption algorithms. The same tool would also track the migration trend from GEA2 to GEA3 and allow an operator to forecast the need for additional SGSN capacity to exceed.
Enhanced counters should display the absolute number of attached subscribers using each of the GEA algorithms.
Counters have been added to the output of the show sub gprs-only summary CLI command to track:
New counters display the number of subscribers whose MS network capability supports GEA0/GEA1/GEA2/GEA3. Similarly, the new counters under “Negotiated” indicate the number of subscribers who have negotiated with the SGSN to use a specific encryption algorithm according to the ciphering priority configuration and the network capability.
The 10 Gigabit Ethernet Line Card is commonly referred to as the XGLC. The XGLC supports higher speed connections to packet core equipment, increases effective throughput between the ST40 and the packet core network, and reduces the number of physical ports needed on the ST40. For more information about this card, refer to the “SGSN Overview” in the SGSN Administration Guide and the ST40 Hardware Installation and Administration Guide.
This section provides information for new features for the Web Element Manager application in Release 9.0.
